Requisitos de los usuarios
Introducción
La ingeniería de requisitos está orientada a garantizar que la especificación satisface las necesidades de clientes y usuarios del sistema.
Los requisitos de usuario derivan de los requisitos de negocio.
Para la elaboración de los requisitos de usuario es fundamental la comunicación con el usuario y la comprensión de sus necesidades.
Representar usuarios arquetípicos: personas.
Saber utilizar casos de uso e historias de usuario.
Saber documentar un caso de uso.
Saber representar escenarios concretos.
Personas
Una persona es a representación de una clase de usuario. Es la descripción de un individuo hipotético que sirve como referencia dentro de un grupo de usuarios que tienen características y necesidades similares
Ayudan al analista a reflexionar sobre los usuarios y sus necesidades, conteniendo información sobre:
Grupo social
Sexo
Comportamientos
Preferencias
Aversiones...
Esta información se recopila en fichas.
Casos de uso e historias de usuario
Casos de uso
Un caso de uso describe una secuencia de interacciones entre un sistema y un actor externo que produce un resultado final valioso para ese actor.
Forma de enunciarlos: Infinitivo + Objeto de la acción.
| Sistema de gestión de productos químicos. | - Solicitar un nuevo producto químico. - Imprimir la ficha de datos de seguridad del producto. - Modificar la solicitud de un producto químico. - Comprobar el estado de un pedido. |
| Puesto de check-in de un aeropuerto. | - Hacer el check-in para un vuelo. - Imprimir las tarjetas de embarque. - Cambiar el asiento de un pasajero. |
Historias de usuario
Una historia de usuario es una descripción corta y simple de una característica, desde la perspectiva del agente que obtiene un beneficio de ella, generalmente un usuario.
Forma de enunciarlos: COMO <rol> QUIERO o DESEO <funcionalidad o evento> PARA <beneficio>.
| Solicitar un nuevo producto químico. | Como técnico de laboratorio deseo solicitar un nuevo producto químico para reponer el almacén y poder realizar mis experimentos. |
| Hacer el check-in para un vuelo. | Como pasajero del avión deseo hacer chek-in en un vuelo para informar a la compañía de que estoy preparado para poder volar a mi destino. |
| Actualizar la información de perfil de un usuario. | Como cliente de la tienda de libros deseo actualizar la información de mi perfil de usuario para que los futuros pedidos se cobren en la tarjeta correcta y se envíen a la dirección adecuada, o actualizar cualquier dato incorrecto. |
Documentación de un caso de uso
Para documentar un caso de uso se utilizan plantillas que indican la secuencia de interacciones del caso de uso.
| 1 | Identificador | Identificación única del caso de uso.Ejemplo: UC-0001 |
| 2 | Nombre | Nombre único del caso de uso.Ejemplo: Actualizar el perfil del usuario |
| 3 | Autores | Nombre de los autores que generaron esta descripción. |
| 4 | Prioridad | Importancia asignada según la técnica de priorización empleada. |
| 5 | Criticidad | Importancia de los posibles daños o perjuicios en caso de fallo. |
| 6 | Fuente | Identificación del origen del caso de uso: stakeholder, objetivo, documento... |
| 7 | Responsable | Stakeholder responsable del caso de uso o persona que lo ha solicitado. |
| 8 | Descripción | Breve descripción del caso de uso. |
| 9 | Evento de activación | Nombre del evento que desencadena este caso de uso. ¿Cómo inicia? |
| 10 | Actores | Listado de los actores que participan en este caso de uso para lograr su objetivo. |
| 11 | Precondiciones | Listado de cero o más restricciones que deben verificarse de manera previa para que el caso de uso pueda tener lugar. |
| 12 | Postcondiciones | Listado de una o varias condiciones que deben darse una vez finalizado el caso de uso, que describen el estado final del sistema. |
| 13 | Resultado | Descripción de los resultados que se producen durante la ejecución del caso de uso. |
| 14 | Escenario principal | Descripción del escenario principal del caso de uso como una secuencia normal de interacciones. |
| 15 | Escenarios alternativos | Descripción de escenarios de ejecución alternativos que se desencadenan por eventos de activación específicos y pueden dar lugar a postcondiciones diferentes a las descritas en [12]. |
| 16 | Escenarios de excepción | Descripción de escenarios de ejecución alternativos que se desencadenan por eventos de activación específicos y pueden dar lugar a postcondiciones diferentes a las descritas en [12]. |
| 17 | Requisitos de calidad | Se indican referencias a los identificadores de requisitos de calidad relacionados. |
Diagramas de casos de uso
Los diagramas de casos de uso proporcionan representación visual de alto nivel de los requisitos del usuario.
Muestran las funciones relevantes del sistema desde la perspectiva del usuario, y relaciones específicas entre las funciones del sistema o entre estas y otros elementos en el contexto del sistema.
Elementos
Los elementos que intervienen en un diagrama de caso de uso son:
Casos de uso: Se representan mediante elipses que contienen el nombre del caso de uso.
Actores. Siempre están fuera de las fronteras del sistema, y representan usuarios u otros sistemas que interactúan con el sistema modelado durante la ejecución de determinados casos de uso.
Las fronteras del sistema: Es el rectángulo que separa los casos de uso de los actores implicados.
Relaciones entre actores y casos de uso: Son líneas que indican comunicaciones entre los casos de uso y actores externos durante la ejecución de algún escenario. Si existe una flecha, esta indica el origen o iniciador de la ejecución del caso de uso.
Relaciones entre casos de uso: Podemos identificar relaciones entre diferentes casos de uso dentro de un mismo diagrama. Podemos identificar dos tipos fundamentales de relaciones entre casos de uso:
Relación de extensión «extend»: El caso de uso A extiende el caso de uso B cuando una secuencia de interacciones o escenario perteneciente a A extiende un escenario en B en un momento dado, siempre que se produzca un determinado evento y de manera opcional.
Relación de inclusión «include»: El caso de uso A está incluido en el caso de uso B cuando para la ejecución de algún escenario contenido en B es necesario ejecutar los pasos de algún escenario contenido en A.
Escenarios
Un escenario define una secuencia de interacciones que se ejecutan para satisfacer un objetivo en un determinado contexto de utilización del sistema.
Ejemplo:
Juan conduce su coche por una carretera a la velocidad de 120 km/h. Pedro conduce el coche de delante. En un momento dado, Pedro frena bruscamente. Juan se da cuenta de que Pedro está frenando y aprieta el pedal de freno. El computador de a bordo de Juan detecta que la distancia de seguridad con el coche de delante es demasiado pequeña y avisa al conductor. La distancia entre los vehículos continúa decreciendo. Para asistir al conductor, el computador inicia un frenado completo automático. El computador informa a Juan sobre la acción de frenado completo automático. Cuando la distancia entre los vehículos deja de decrecer el computador finaliza la acción de frenado automático. El computador continúa controlando la velocidad del vehículo de Juan hasta que la distancia de seguridad alcanza el valor admisible. Cuando la distancia de seguridad se estabiliza el computador informa a Juan de que la maniobra de asistencia ha finalizado.
Tipos de escenarios
Flujo normal: representa la secuencia más habitual de ejecución y la que se espera en condiciones normales.
Flujos alternativos: describen otros escenarios de éxito dentro de un caso de uso, dando lugar a los mismos resultados que el principal pero indicando variaciones sobre el flujo normal.
Excepciones: Son eventos inesperados que se producen en los escenarios anteriores, dando como resultado final algo no esperado.
Cuando detectamos una excepción podemos hacer dos cosas:
Gestionar la excepción indicando el comportamiento deseado cuando se produce.
Ignorar la excepción y aceptar el riesgo de que el evento pueda causar daños.
Ejemplo:
Supongamos un sistema de control ferroviario que por seguridad está diseñado para enviar de manera redundante dos señales independientes a un tren. Si en un momento dado las dos señales no coinciden —por ejemplo, una indica que se debe reducir la velocidad a 20km/h y la otra que se debe continuar a velocidad máxima—, ¿qué acción debería tomar el sistema?
Es útil representar los distintos flujos de ejecución posible mediante diagramas de actividad:
